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a full assignment, the user is preferably prompted to 
enter a new Party A or Party B. The original ticket 
with amended Party A or Party B is then sent through 
the workflow. In the case of partial assignment, the 
5 user is preferably prompted for the assigned notional 
amount and the new Party A or Party B for the assigned 
amount. A new Deal in Progress for the assigned amount 
may then be authorized by the trader and sent through 
the workflow. The original ticket with amended 

10 notional amount is then sent through the workflow. 

An audit trail of all changes made to an 
authorized deal may be maintained. Each time a 
proposed edit to a deal is applied by a trader, a 
static copy of the historical version of the deal is 

15 stored on the database. The user can display a dialog 
box summarizing the changes. The user can also select 
any change with the mouse and display a complete 
historical version of the deal. The user can further 
display a dialog box summarizing the deal's current 

2 0 state and an audit trail of its state transition 

history. The state transition history records state 
transitions, the name of the user initiating the state 
transition, and the time it was initiated (see Fig. 
10). The confirmation status of the deal may also be 
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displayed, including whether the confirmation has been 
sent, or signed and returned. This feature thus 
permits a client to access the state transition history 
of a deal. 

5 

FILE PROCESSING 

This section describes a preferred method of 
processing filed in the system of the present 
invention. Files may be Custom Templates, Deals in 

10 Progress, or authorized deals. 

New files in the system may be created as 
Deals in Progress or Custom Templates. A Deal in 
Progress is created when a System Template, a Custom 
Template, or an authorized deal is saved by the user as 

15 a Deal in Progress. A Custom Template is created when 
a System Template, a Custom Template, or an authorized 
deal is saved by the user as a Custom Template. This 
method of Creating New Files allows a user to open an 
existing file for the sole purpose of saving it as a 

20 new file owned by that user. 

Users may browse files across all states in 
the system, may filter on approximately 50 fields (see 
Fig. 9), and may specify which fields are included in 
the result set. In addition to being able to drill 
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down to the deal level directly from the file browser, 
the user can save favorite queries, and print or 
download result sets to a spreadsheet. In addition, 
the user can quickly re-access the four most recently 
5 used files in system. 

System files may be opened by users in Write 
Mode, or in Read-only Mode. Whether a file may be 
opened, and it what mode it may be opened, is dependent 
on File Edit Permissions and File Write Lock. When a 

10 deal is open in Write Mode all system fields that a 
user has Edit Permissions for are editable. When a 
user attempts to open a file in Write Mode, the system 
checks whether that user already has another deal open 
for writing, or whether a second user has the same deal 

15 open for writing. If the first user already has a deal 
open for writing, the user is advised that two files 
cannot be simultaneously open for writing. The user 
then has the option of either closing the first file, 
or of opening the second file in Read-only Mode. If a 

20 second user has the same file open for writing, the 
first user is informed of the time the file was write 
locked, and the identity of the second user. The first 
user has the option of opening the second file in Read- 
only Mode. 
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File edit permissions are determined by deal 
state and user profile. When a user attempts to open a 
file in Write Mode, the system checks whether that user 
has permission to edit that file based on the functions 
5 associated with the group to which the user belongs. 
The system preferably checks whether the file is 
editable based on the state in which the deal is. In 
either case, the user is advised that the file is not 
editable, and the reason it is not editable. The user 

10 then has the option of opening the second file in Read- 
only Mode. When a deal is open in Read-only Mode, no 
system fields are editable. 

Custom Templates and Deals in Progress are 
treated as the property of the user that creates them. 

15 Ownership of a Custom Template implies the ability to 
view it, to edit it, or to change viewing permissions, 
while ownership of a Deal in Progress implies the 
ability to view it, to edit it, or to enter it into the 
workflow. Files are generally viewable by all users 

2 0 through the deal browser, with the exception of Custom 
Templates and Deals in Progress . Since each user may 
be maintaining a number of Custom Templates and Deals 
in Progress, viewing will initially be limited to the 
file owner. Users can transfer Custom Template 
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ownership to another user. This function is typically 
invoked if first user no longer wanted to maintain or 
control access to the Custom Template. Users also can 
share Custom Templates by opening up view permssions to 
5 other users. A user with view permissions would not be 
allowed to edit a Custom Template, but would be able to 
save and become the owner of a new version of it. Deal 
in Progress ownership and view permissions are changed 
in the system workflow as a Deal in Progress Transfer, 

10 described above. 

Files that are open for writing may be 
"closed clean". If the file was open in Read-only 
Mode, the file will be dismissed from the screen. If 
the file was open for writing, the user will be 

15 prompted to save changes. 

PAYMENT AND RISK MANAGEMENT VIEWS 

This section describes a preferred payment 
and risk management views of the system of the present 
20 invention. The Payment (Customer) View of the deal is 
the way the deal is captured in system, and the way the 
deal is preferably referenced in documentation between 
the investment bank house and the counterparty. The 
Risk Management View of the deal is the way the legs of 
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a deal must be broken up on the investment bank's risk 
management and payment systems. The system captures 
both views, as follows. 

The payment view of a deal is created as deal 
5 information is captured. This is the default view in 
the system. Initially, the Risk Management View and 
the Payment View are the same. This is because in the 
case of generic deals , the payment legs of a deal may 
be acceptable as risk management legs . The Middle 

10 Office reviews all payment legs to verify that they can 
be booked in risk management systems. If a payment leg 
cannot be used as a risk management leg, however, the 
Middle Office has to create risk management legs in 
System. Middle Office users are then required to 

15 specify which risk management system on which each risk 
management leg is booked. When a deal is opened in 
Write Mode or in Read-only Mode, the Payment View will 
be presented. The user can switch to the Risk 
Management View by selecting a menu item. When the 

2 0 Risk Management View is being displayed it is 
preferably prominently indicated on the screen. 

ADMINISTRATIVE FUNCTION 
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This section describes the administrative 
functions preferably implemented in the system of the 
present invention. These administrative functions 
ensure that system security is enforced, that deal 
5 information is captured correctly, that new product 
types are identified and accounted for in the template 
structure, and that tickets move smoothly through the 
workflow. 

User preferences are user level 
10 administration functions that allow customization of 
default settings, workflows, and filter criteria. 
The User Profile contains information about each user's 
System administrative privileges and group membership. 
This information is viewable at the user level, but 
15 editable only by someone with User Profile 
Administration privileges . Middle Office 
administrative users are preferably responsible for 
creating, updating, and deleting system User Profiles. 
Middle Office administrative users are also preferably 
20 responsible for maintaining system User Groups. This 

includes defining system privileges for each User Group 
and assigning individual users to User Groups. 

Middle office administrative users are also 
preferably responsible for creating, updating, and 
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deleting system System Templates, and monitoring the 
comment field of all deals for information that cannot 
be captured on an existing Template. If the data could 
have been captured on an existing Template, the user 
5 generates a proposed edit; otherwise, the user either 
adds an existing field to a System Template, or defines 
a new field and adds it to the System Template. By 
adding a new field, an existing System template may be 
modified, or a new System template may be created. The 

10 ticket may then be re-submitted for Trader 

Authorization as a proposed edit as described above, 
and the comment field is empty. 

To ensure that tickets are processed in a 
timely manner, middle office administrative users 

15 preferably monitor the number of deals in the workflow 
in each state. Using the file browser, they can view 
deals across all states. 

ADDITIONAL FUNCTIONS 
20 This section describes certain additional 

functions which may be implemented to enhance the 
capturing and processing of deals, as described above. 
First, system users can print files open in Write Mode 
or Read-only Mode, and can select and deselect deal 
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components to be printed through a dialog box. In 
addition, users can define the output format of the 
printed ticket. All print selections are viewable 
through a print preview function. Further, the system 
5 can generate "drop copies" of tickets at specified 
times, such as state transitions. 

If a file is open for writing, the user may 
be allowed to discard any changes made to the file 
since it was opened by invoking a "revert to last saved 
10 version of a file" function. A dialog box asks the 

user to confirm the action and advises that any changes 
will be lost. If confirmed, the file is then closed 
without saving changes and the last saved version is 
re-opened. 

15 If a file is open for writing, the user may 

be allowed to return all fields to their defaulting 
values by invoking a "revert to field defaults" 
function. A dialog box asks the user to confirm the 
action and advises that any changes to fields with 

20 defaulting values will be lost. 

If a file is open for writing, the user may 
be allowed to clear all data, including defaulting 
values, from fields on the file by invoking a "clearing 
all fields" function. A dialog box will ask the user 
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to confirm the action and advise that any data in 
fields will be lost. 

Generic text edit functions, such as those 
typically found in Microsoft applications, are made 
5 available to the user. For example, the user may cut, 
copy, and paste text items. 

Based on captured trade data, a graphical 
flow diagram of all legs is generated for viewing and 
printing. 

10 While the present invention has been 

described in detail with reference to the preferred 
embodiments thereof, many modifications and variations 
thereof will be readily apparent to those skilled in 
the art. Accordingly, the scope of the invention is 

15 not to be limited by the details of the preferred 

embodiments described above, but only by the terms of 
the appended claims. 



